前兩天講的都還停留在「一個人」的層級：AI 把知識的取得成本壓到很低，但判斷答案對不對的成本一點都沒降。

今天把範圍拉大到整個團隊。

先講結論：標題所寫的問題不是 AI 帶來的。在沒有 AI 的年代就一直存在，AI 只是讓它擴大得非常快。

沒有 AI 的年代，通常團隊知識是這樣傳下去的

一個人摸熟了某個東西，某支測試為什麼要這樣設計、某個環境為什麼會踩雷、某個 selector 為什麼不能用，接下來要做的事情很固定：

• 寫成文件、錄影等等
• 開會分享同步
• 放進團隊共編筆記，讓後面的人可以接手

這套做法在小團隊通常滿有效的。
因為小團隊有一個很強的前提：大家工作都是緊密的。

文件只要寫重點就好，寫不清楚的部分，走過去問一句就補完了。
文件負責記錄結論，「補完理解」這件事由人跟人之間的距離去完成。

團隊一變大，同一套做法就容易開始漏

而是團隊一大，通常會同時出現三個小團隊沒有的狀況：

第一，成員的能力分歧會變大。

小團隊裡大家的技術水準通常落差不大，你通常可以預設一條共同的基準線，哪怕仍有人看不懂，你也可以與快速與對方對齊即可

但是團隊一大，這條線就容易模糊。

因為同一份文件，一定有有人覺得太淺、一定也有人覺得完全看不懂。

這也是更加強放大 Junior、Senior 的一些差距存在，甚至 AI 迭代速度太快，也就更容出現落差了

此時若仍跟以前一樣與對方對齊資訊，那你可能一天就要對齊好幾十次，這絕對是很耗費時間的一件事情

第二，沒有人有空把你的文件看完。

先說：這不是再說對方態度有問題哦！

是每個人手上都有自己的專案進度要趕、自己的火要救。

你花兩三小時寫的文件，對他來說是可能就是「等我忙完再看」，然後...就沒有然後了XDDD。

結果就很容易出現：今天分享完，三週後突然有人來問這個文件的問題，再過三週又會有其他人來問相似的問題

第三，產品支線變多。

大團隊通常代表產品線多、系統多、環境多。

需要傳承的知識量本身就變大，而且是散在各處的。

三件事加起來，結果就是：

文件確實寫了，但團隊共用知識層還是斷了。

寫文件這件事沒有失效！是它的「到達率」變低了。

簡單整理比對後：

所以文件本身要換一種寫法

我時常會假設讀的人不具備你腦中那些背景。

所以文件會被迫變成另一種樣子：

• 用字要更白話
• 要給足夠的情境舉例，而不是只給規則
• 要把「為什麼」寫進去，會「影響到什麼」，不能單純只寫「怎麼做」
• 盡量預先想好對方可能會卡在哪一步，先把那一步補上

注意：目前都只解決了「人看」的部分

到目前為止，所有的努力都建立在同一個前提上：

會有人去讀它。

你可以把文件寫得再白、範例準備得再齊全，只要沒有人打開它，它其實也就等於不存在。

AI 讓這個斷層裂得更快

接下來才是真正麻煩的地方。

回到 Day1 和 Day2 講的兩件事：

• 取得答案的成本降到接近零
• 但判斷答案對不對的成本，一點都沒有降

當整個團隊都開始用 AI，這兩件事會被同時放大。

一個人不去驗證 AI 的結論，可能頂多就一個人的風險。

一群人都不驗證，那就不是風險了，那是團隊的預設行為。

而且還有更現實的一層：AI 讓每個人的產出速度都變快了。

所以這篇核心主軸還是：

AI 沒有製造知識斷層，它只是讓原本就存在的斷層，用十倍速裂開。

文件知識傳承由 AI 來承接

既然「靠人主動去讀」這條路在大團隊注定會漏，那就換一個載體。

現在做的事情，是把知識寫成 「AI 讀得懂，人也讀得懂」 的形式。

差別在這裡：

要把斷層的門檻壓低，就得讓知識在工作(AI)發生的那一刻自動生效，而不是等人手動去找它。

總結

整理成三句話：

1. 知識斷層是團隊規模的產物，跟 AI 無關，它一直都在
2. AI 沒有製造它，但因為判斷力沒有跟著被複製，AI 讓它擴大得非常快
3. 解法不是寫更多文件，而是換一個人跟 AI 都讀得到的載體

下篇會講到在 AI 應用之下，該如何真正讓文件「到達率」有效的發揮作用 => Skill